home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / MotifApp / RELEASENOTES < prev    next >
Encoding:
Text File  |  1995-05-03  |  9.9 KB  |  246 lines

  1. LAST UPDATE: July 15, 1992
  2.  
  3. All examples have been built successfully with Motif 1.1.3, 1.1.4, and 1.2,
  4. as well as C++ 2.1 and C++ 3.0 on a Silicon Graphics IRIS Indigo. Note that
  5. a few minor changes from the sources described in the book were required to
  6. compile under C++ 3.0 and Motif 1.2. More details below.
  7.  
  8. The sources are mostly organized by chapters, with each example being
  9. placed in a directory that corresponds to the chapter in which it is
  10. discussed. The exception is those C++ classes that are considerred part of
  11. a library. There are two libraries.  The first is libComponent.a, used by
  12. the first part of the book. This is a very small library, and those classes
  13. are found in the ComponentLib directory. The second, somewhat larger
  14. library is libMotifApp.a, which is developed in the second part of the
  15. book.  This library lives in the MotifApp directory.
  16.  
  17. If you have lots of disk space, just type "make" in this top-level
  18. directory to build all examples. You can also type "make clobber" to remove
  19. all binaries from subdirectories. If you have less disk space, just build
  20. the libraries and build only those examples you are interested in.
  21.  
  22. The Makefiles have been kept very simple to allow you to modify them to
  23. meet your needs. They make no pretense at being robust or portable. They
  24. are not tested
  25.  
  26. In addition to the sources to the examples in the book, you will find an
  27. "Extras" subdirectory. This directory contains a few alternate
  28. implementations of some examples in the book, and also contains some
  29. written material that was cut from the final version of the book, but which
  30. may be useful to some people.
  31.  
  32. CHANGES FOR C++ 3.0
  33.  
  34. The TicTacToe uses enumerated types encapsulated within a class.
  35. Unfortunately, the way C++ treats such types changed between 2.0 and 3.0,
  36. and it appears to be impossible to come up with an approach that satifies
  37. both and keeps the type encpasulated.  These types have been moved outside
  38. the class to accomodate both versions of C++, at the loss of encapsulation.
  39.  
  40. CHANGES FOR MOTIF 1.2 AND R5
  41.  
  42. To build these examples with X11 R5 and Motif 1.2, you must change all
  43. declarations of argc as an unsigned int to be just an int. These have been
  44. ifdef'd with
  45.  
  46. #if (XlibSpecificationRelease>=5)
  47.  
  48. in the examples. 
  49.  
  50. The call to XrmMergeDatabases() in UIComponent seems to cause problems in
  51. R5, as well. Using the new R5 function, XrmCombineDatabase, when building
  52. with R5 seems to solve the problem.
  53.  
  54. Note that for R5, no compilation flags are necessary to activate function
  55. prototypes in Xt.
  56.  
  57. BUILD PROBLEMS WITH Motif 1.1
  58.  
  59. Some vendor's distributions of Motif appear to still have C++ keywords in
  60. public header files. If you encounter compile errors due to the words "new"
  61. or "class" in a Motif header, simply change the offending variable names to
  62. something else. These problems appear to be completely gone in Motif 1.2.
  63.  
  64. Also: Some versions of Xt (R4) expect XTFUNCPROTO to be defined instead of
  65. FUNCPROTO, as discussed in the book. The makefiles have been modified to
  66. use both.
  67.  
  68. PORTABILITY PROBLEMS
  69.  
  70. Someone pointed out that I use the function strdup() periodically, which is
  71. a non-standard function.  If you don't have this function, it is simple to
  72. write an equivalent, of course:
  73.  
  74. char * my_strdup(const char *str)
  75. {
  76.    // not robust, but neither is strdup
  77.  
  78.    char *newStr = new char[strlen(str) + 1];
  79.    strcpy(newStr, str);
  80.    return (newStr);
  81. }
  82.  
  83. srand48/drand48 is apparently not available on all systems. A contributed
  84. (untested) fix is to put these lines in the MoveGenerator class file:
  85.  
  86.     #include "stdlib.h"
  87.     void srand48(long seed){srand((int)seed);}
  88.     #define RAND_MAX 2147483647  // should not be needed
  89.     double drand48(void){ return ((double)rand())/(double)RAND_MAX; }
  90.  
  91.  
  92. I have had several other reports of trouble compiling with g++.  However,
  93. many people report success at building with an assortment of other
  94. compilers. Known problems with g++:
  95.  
  96.  In ButtonInterface.C, the call to XtAddCallback references a protected
  97.  static member of the CmdInterface base class as
  98.  CmdInterface::executeCmdCallback. g++ doesn't like this, but will accept
  99.  just executeCmdCallback.
  100.  
  101.  In some cases g++ doesn't appear to properly initialize non-local static
  102.  objects, MotifApp's UndoCmd, for example. A contributed solution is to 
  103.  include UndoCmd.h in the same file as main, which g++ then handles correctly
  104.  for some reason.
  105.  
  106. IMPORTANT NOTE: There is an assumption in the approach described and
  107. demonstrated in the book that calling conventions between C and C++ are the
  108. same. Specifically, it is expected that the argument order of static member
  109. functions is the same as that of C functions, so that static member
  110. functions can be registered as callbacks and called from C.  This is
  111. generally true of most current C++ compilers, but the C++ spec allows for
  112. implementations that do not meet this criteria. Reportedly, there is at
  113. least one native compiler implementation whose calling conventions passes
  114. C++ arguments in the reverse order of that used by C! For such a compiler,
  115. these sources will obviously not work. The concepts in the book are still
  116. valid, but as an implementation issue, if you have such a compiler, you
  117. must use friend functions rather than static member functions, as initially
  118. described in the book, and you must declared these functions as extern "C".
  119.  
  120.  
  121. ERRORS FOUND IN FIRST PRINTING
  122.  
  123. Page 62:
  124. --------
  125.  
  126. Line 10 in the code example is not needed. There is no regular
  127. checkPassWord() function. This is a left-over from the previous example.
  128. To be fixed in a future printing.
  129.  
  130. Page 229
  131. -------
  132.  
  133. SetValues should use MODAL, not MODEL
  134.  
  135. Page 374
  136. --------
  137.  
  138. Callbacks are installed incorrectly, Both a cancel and an ok callback
  139. should be installed. In the text, the cancel is installed as the
  140. okCallback.
  141.  
  142. HSView class, page 367
  143. ----------------------
  144.  
  145. The protected member function should be declared  as:
  146.  
  147.    void RGBToHSV ( int, int, int, int&, int&, int& );
  148.  
  149. not as:
  150.  
  151.    void HSVView::RGBToHSV ( int, int, int, int&, int&, int& );
  152.  
  153. No harm done, at least with my compiler, but the class qualification is
  154. unecessary.
  155.  
  156. WordCountWindow class, chapter 10, page 326
  157. --------------------------------------------
  158.  
  159. The member function createMenuPanes() should be declared as:
  160.  
  161. virtual void createMenuPanes();
  162.  
  163. not
  164.  
  165. virtual void WordCountWindow::createMenuPanes();
  166.  
  167.  
  168. NAME CHANGES: 
  169.  
  170. In the stopwatch and tictactoe examples, found in directories ch3A, ch3B,
  171. and ch5, the names of the driver or body of the programs, as used in the
  172. book, had the same name as a class in the same directory, but with a
  173. different case. For example, main() is defined in tictactoe.C, in the book.
  174. This causes installation problems when loaded on systems that are not case
  175. sensitive (PCs and Macs). Therefore, the problem files in these directories
  176. have been renamed "main.C".
  177.  
  178. VARIOUS CLASSES IN MOTIFAPP DIRECTORY:
  179.  
  180. All examples were tested using a 2.0 cfront that had a number of 2.1
  181. features implemented. Among them - 2.1 allows classes to inherit pure
  182. virtual member functions, pure 2.0 does not. Several classes, as described
  183. in the book expect to inherit pure virtuals. I have added the the pure
  184. virtual declaration in the derived classes to the sources for those using
  185. 2.0 C++. These are ifdef'd with "#ifndef CPLUSPLUS2_1" to indicate the
  186. changes. The added declaration will work with both 2.0 and 2.1. The ifdef
  187. is purely to indicate something that is different from the text of the
  188. book.
  189.  
  190.  
  191. PROBLEMS IN TEXT, SECOND PARAGRAPH, page 87
  192.  
  193. This paragraph is misleading. A future printing will read:
  194.  
  195. The Intrinsics destruction sequence for widgets can be particularly
  196. troublesome, although necessary. For example, consider the stopwatch
  197. example described earlier in this chapter. If the application were to
  198. destroy the program's top-level shell widget before deleting the Stopwatch
  199. object, the integrity of every object in the Stopwatch subsystem would be
  200. compromised. When a widget is destroyed, Xt automatically destroys all the
  201. widget's children. So, destroying a widget that serves as the parent of a
  202. Stopwatch object ultimately destroys the widgets created by the Stopwatch
  203. object, and also the widgets created by the Face and Control objects.
  204. Therefore, destroying a widget can potentially free data members that are
  205. supposedly accessible only from within an object. This represents a fairly
  206. serious breach in the encapsulation of the component. Although this
  207. scenario may seem contrived, such situations can easily occur in more
  208. complex programs
  209.  
  210.  
  211. PAGES 108-109
  212.  
  213. A last minute reorganization produced some backward references to things
  214. that had not yet been introduced:
  215.  
  216. 1ST FULL PARAGRAPH, page 108, should read:
  217.  
  218. Derived classes may be either specializations or generalizations of the
  219. original base class. Specializations start from a general-purpose base
  220. class and move toward a specific purpose. For example, Chapter 2 starts
  221. with a general Password class and then derives a StrictPassword class that
  222. adds additional features and alters the behavior of the base class.
  223. Sometimes the derived class adds additional features and is intended to be
  224. used in a wider range of situations than the base class. For example, the
  225. UIComponent class extends the protocol defined by the BasicComponent class
  226. to provide a more generally useful class.
  227.  
  228. 1st FULL PARAGRAPH, page 109, should read:
  229.  
  230. Sometimes it is clear that a task needs to be performed, but it is less
  231. clear which object should do it. It is useful to consider all the
  232. activities in a system and be sure some object is responsible for each
  233. action. Sometimes, the responsibility for a particular task can be assigned
  234. to an object that has already been identified. At other times, the action
  235. may suggest that a new type of object should be added to the system. For
  236. example, in the Password class discussed in Chapter 2, it is apparent that
  237. there is a need to maintain a list of valid passwords somewhere. We might
  238. decide that this responsibility does not really belong in the user
  239. interface component that accepts the password from the user. Instead, we
  240. could create a second class, a PasswordDatabase class, to perform that
  241. function.
  242.  
  243.  
  244.  
  245.  
  246.